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Chapter  IV  reviews  major  concepts  employed  in  t;ie  Inventory 
System  Simulator.  The  chapter  defines  timing  mechanism  employed 
by  the  simulation,  the  raajor  events  that  are  simulated  within 
the  model,  and  the  subroarinos  and  data  files  that  arc  required 
to  perform  the  associated  bookkeeping  functions.  Most  of  the 
major  INSSI”  variables  are  defined  in  this  chapter. 

Chapter  V discusses  the  operations  of  the  MAIN  program. 

This  program  is  the  workhorse  of  the  simulation.  This  routine 
is  responsible  for  the  control  of  input  data,  initializa- 
tion of  status  and  performance  variables,  the  scheduling  of 
sim.ulation  events,  and  the  control  of  output  products.  Flow 
charts  and  a detailed  discussion  of  this  routine  is  nrcsented 
in  Chapter  V. 

An  important  feature  of  tlie  It;ssir:  model  is  the  capability 
to  simulate  inventory  diemand  patterns  so  as  to  exactly  duplicate 
the  demand  patterns  recorded  in  D0G2  history  files.  Cliaptcr 
VI  describes  tlie  demand  generation  process  by  v;hich  this  is 
accomplished. 

To  users,  the  most  important  feature  of  any  model  is  its 
input  requirements  and  the  associated  output  products.  These 
arc  the  topics  of  Chapters  VII  and  VIII.  Input  requirements 
for  the  model  are  discussed  in  detail  in  Chapter  VII  v/hilo 
output  products  are  discussed  in  the  following  chapter. 
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CHAPTER  II.  The  EOQ  Buy  Computation  System 

The  EOQ  Buy  Computation  System  (D062)  is  the  primary 
data  system  for  the  control  of  stock  fund  items  managed  by 
the  Air  Force  Logistics  Command.  In  general,  this  system 
manages  discrete  components  that  are  part  of  a higher 
assembly  and  are  not  economically  reparable  at  the  depot 
level  of  supply.  The  terms  "repair  parts,"  "bits  and 
pieces,"  "consumable  items,"  "stock  fund  items,"  and  ''expense 
items"  are  often  used  to  describe  these  parts.  AFLC  manages 
approximately  500,000  of  these  items. 

The  primary  functions  of  the  EOQ  Buy  Computation  System 
are  to: 

a.  Accumulate  demand  data. 

b.  Compute  depot  stock  levels. 

c.  Determine  buy,  termination,  and  long  supply 
quantities. 

d.  Provide  a baseline  for  funds  projections. 

e.  Provide  reports  and  management  data. 

As  illustrated  in  Figure  II-l,  inputs  to  D062  come  from 
several  sources.  Headquarters  AFLC  specifies  the  implied 
shortage  factor  (\)  required  by  the  Presutti-Trepp  safety 
stock  formula.  Stock  list  data,  asset  and  usage  counts, 
and  file  maintenance  actions  are  other  inputs  to  the  D062 
system. 
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This  information  is  used  to  compute  severi^l  critical 
nurxhers,  called  "levels,"  that  are  used  to  initiate  manage- 
ment notices  on  a by  exception  basis.  For  example,  currently 
available  assets  are  compared  to  the  levels  to  determine  if 
buy,  termination,  or  disposal  actions  are  needed. 

Figure  II-2  illustrates  the  major  outputs  of  the  D062 
System.  These  include: 


a.  Requireraents  Notices  — The  item  manager  receives 

advance  buy,  buy,  or  termination  notices  v;hen 
assets  breacli  the  respective  levels.  Item 
interrogations  can  also  be  requested  by  the 
item  manager. 

b.  Ilanagemcnt  Reports  — These  data  products  are 

produced  for  the  jhir  Logistics  Centers  and 
Headquarters  AFLC  summarizing  the  impact  of 
tlie  computation  by  categorizing  items  accord- 
ing to  actions  required. 

c.  CSIS  Data  — Data  required  to  perform  the  Central 

Secondary  Item  Stratifaction  is  passed  to  the 
D075  system  every  quarter. 


d.  Data  to  Other  Interfacing  Systems  — DOG 2 also 
provides  information  to  the  DOG 7 and  DO 32 
systems.  DOG 7 is  furnished  data  required  to 
process  excesses,  and  D032  is  fed  control 
levels  required  for  distribution  of  assets. 

Control  Levels 


In  the  D0G2  system,  the  terms  "asset  position"  and 
"inventory  position"  refer  to  the  total  assets  on  hand 
and  on  order  in  the  system,  less  any  backorders. 

Hence,  an  item's  asset  position  is  the  total  stock  avail- 
able to  meet  future  demands  if  there  are  no  more  buys. 


Figure  II  -2.  Outputs  from  the  UOQ  Buy  Computation  System 


As  noted  above,  D062  computes  various  "level 


v/hich  are 


compared  against  an  item's  asset  position  to  determine  if 


are  summa 


time  that  elapses  from  the  first  printout  of  a buy  notice 


to  the  date  of  the  first  significant  delivery.  The  safety 


HQ  AFLC  input 


Its  purpose  is  to  insure  continuous 


operation  in  the  event  of  unpredicted  fluctuation  in 


demand  and/or  extended  lead  times 


The  reorder  level  (ROL)  equals  the  number  of  demand 


determine  if  a buy  action  is  required.  When  an  item's 


inventory  position  equals  or  falls  belov;  the  reorder  level 


the  buy  quantity  consists  of  any  deficiency  to  the  reorder 


level  plus  an  economic  order  quantity 


The  data  level  represents  four  months  of  demands  beyond 


the  reorder  level.  The  function  of  the  data  level  is  to 


The  termination  level  is  one  years  worth  of  demands 


beyond  the  ROL.  Note:  If  EOQ  > one  year's  supply,  the 


termination  level  = ROL  + EOQ.  Termination  level  notices 
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Figure  11-3#  Levels 
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Figure  II  -4.  More  Levels 
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are  output  for  itoKis  with  on  order  assets  v;hen  the  total 
asset  position  is  greater  than  the  terrainatioh  level.  This 
notice  v/arns  the  item  manager  that  it  way  be  desirable  to 
cancel  delivery  of  at  least  part  of  the  on  order  quantities. 
The  approved  force  iicquisition  objective  (AF/\0)  consists  of 
two  years  v/ortii  of  forecast  demands  plus  t)'ie  lead  tine  and 
safety  level  requirements.  (IJotc:  If  EOp  > 2 years  of 
supply,  AFAO  = EOQ  + ROL.)  Items  with  assets  greater  than 
the  AFAO  are  considered  to  be  in  long  supply. 

Finally,  the  retention  level  indicates  the  manimura 
amount  of  stock  v;hich  laay  be  retained  in  the  supply  system. 
Generally,  quantities  beyond  this  value  are  considered 
excess.  Retention  levels  can  vary  from  one  to  five  years  of 
projected  demands  beyond  the  AFAO.  Retention  levels  for 
items  supporting  nev;er  weapon  systems  generally  use  five 
years,  while  systems  ready  to  be  phased  out  may  have  reten- 
tion levels  equal  to  the  AFAO  plus  one  year  of  projected 
demands. 

Formulas 

A basic  problem  in  any  inventory  system  is  determining 
how  much  stock  should  be  on  hand.  If  too  much  stocl:  is 
procured,  excessive  carrying  costs  are  incurred.  On  the 
other  hand,  if  too  little  stock  is  procured,  an  item  must 
be  procured  wore  often,  and  excessive  procurement  costs  are 


{ 
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incurred.  In  the  D062  system,  the  VJilson  lob  size  formula 
is  used  to  obtain  a good  balance  between  these  conflicting 
costs.  This  formula  takes  the  form; 


whore  Q equals  the  order  quantity  in  units,  D is  the  annual 
demand  rate  in  units,  A is  the  cost  per  order  placed,  and  H 
is  the  cost  of  holding  one  unit  in  inventory  for  one  year. 

At  present,  a holding  cost  H of  20%  of  the  item  unit  cost 
per  year  is  used  in  the  lot  size  formula. 

In  Air  Force  supply  systems,  different  procurement 
methods  are  employed  for  small  purchases  than  are  used  for 
high  dollar  buys.  Simplified  procurement  techniques  are 
used  for  small  dollar  purchases.  These  methods  may  bo  used 
for  purchases  of  less  than  $10,000.  On  the  other  hand, 
advertized,  negotiated  contracts  arc  used  for  high  dollar 
buys.  At  present,  the  following  order  costs  are  used  in  the 
D062  system: 

COST  TO  ORDER 

$269.87  for  purchases  of  less  than  $10,000 

$460.27  otherwise 

In  applying  the  EOQ  formula  above,  impractical  values 


or  with  vory  lov/  annual  demand  rates.  Conseiyaontly , EOQ's 
are  bounded  to  be  no  more  than  a 36  month  supply,  and  no 


less  than  a 6 month  supply.  i 

At  present,  safety  levels  are  computed  in  D062  using  the  ] 

Presutti-Tropp  formula  v;ith  Z = /r.  This  quantity  is  then  | 

bounded  to  be  no  more  than  (a)  the  number  of  demands  expected  ; 

in  the  procurement  lead  time  or  (b)  three  times  the  standard  ; 

deviation  of  lead  time  demand,  v/hichever  is  smaller. 

Figure  II-5  illustrates  the  levels  computations  for  a 
particular,  fast  moving  item.  This  item  has  a unit  price  ' 

[ of  $10,  a procurement  lead  time  of  nine  months,  and  an 


average  of  100  demands  per  month.  The  expected  demand  in 
the  nine  month  procurement  lead  time  is  thus  9 X 100  = 900 
units.  The  safety  level  for  this  particular  item  is  113. 
This  was  determined  based  on  the  PT-safety  level  formula. 
The  reorder  level  is  the  sum  of  the  safety  level  and  the 
expected  demand  in  the  procurement  lead  time,  which  gives 
us  113  + 900  = 1013.  The  data  level  is  four  months  worth 
of  demands  beyond  the  reorder  level.  This  item  has  annual 
demands  D of  1200  units  per  year,  and  the  cost  of  holding 
one  unit  in  inventory  for  one  year  is  20%  X unit  price  = 

$2  per  year.  Hence,  the  EOQ  is  (lAD/li  = /2  X ($269)  X 


(1200)/$2,  or  568  units.  A cost  per  order  of  $269  is  used 
in  this  calculation  since  the  dollar  value  of  the  purchase 


Figure  II-5<i  Levels  Coiriputatlon 
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CHAPTER  III.  INSSIM  - The  Inventory  System  Simulator 

0 

As  noted  above,  a detailed  simulation  model  of  the  D062 
system  was  needed  to  evaluate  the  relative  of fectivenoss  of 
the  alternate  PT- formulas.  In  our  study,  wo  utilized  the 
Inventory  System  Simulator  (INSSI'l)  as  a starting  point. 

This  simulator  v/as  developed  by  the  Directorate  of  Manage- 
ment Sciences  (AFLC/XRS)  to  evaluate  inventory  policies  in 
single  location  supply  systems.  For  our  study,  it  was 
necessary  to  enhance  the  oi'iginal  model  to  provide  a de- 
tailed description  of  the  current  DOG 2 systeia  and  to  provide 
for  improved  input  and  output  capabilities.  In  the  follow- 
ing discussions,  we  will  use  the  term  "INSSIM"  to  refer  to 
the  enhanced  version  of  the  original  simulator. 

Major  Features  of  the  Inventory  System  Simulator  (INSSTM) 

The  Inventory  System  Simulator  (as  enhanced)  possesses 
the  following  major  characteristics: 

a.  A detailed  description  of  the  EOQ  Buy  Computation 

System  {D062) . 

b.  A demand  process  leased  upon  actual  demand  his- 

tories for  Air  Force  items. 

c.  Comprehensive  measurement  of  simulation  results. 

d.  Entensive  input  options  — which  permit  the  evalua- 

tion of  several  proposed  forecasting  and 
inventory  control  policies  by  simple  changes 
to  input  data. 

e.  A modular  structure  — to  simplify  future  enhance- 

ments to  the  model. 
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f.  Debugging  aids  — to  assist  in  the  progranuaing 
of  proposed  rules  that  are  not  already  coded 
in  the  model. 


Basically,  INSSIM  consists  of  a collection  of  Fortran 
subroutines  and  a ILMK  program  that  controls  input  rof]uire- 
ments,  schedules  events  v.’ithin  the  simulation,  and  initiator 
output  products.  The  major  INSSin  routines  are  illustrated 
in  Figure  III-l,  grouped  by  their  major  function.  As  sliovm 
in  the  figure,  the  major  features  of  the  D062  system  are 
simulated  using  subroutines  FOR576,  FORUPD,  LEVEL,  and 
STATUS.  The  major  functions  of  these  routines  are  as 
follov;s : 


Siibroutine 


Function 


Description 


FOR576 


Forecasting 


This  routine  provides  estimates 
of 


FORUPD 


Record  demand 
history 


® gross  demand  rates 
“ serviceable  return  rates 
® net  demand  rates 
° average  requisition  size 
® demand  variability 

This  routine  maintains  an 
eight  quarter  moving  history 
of  simulated  demand.  This 
history  is  used  in  the  fore- 
casting calculations  in 
FOR576. 


LEVEL 


Computes  This  routine  computes  the 

inventory  inventory  control  levels  dis- 

control  cussed  above  (safety  levels, 

levels  reorder  levels,  etc.) 


/ 


INFEL 

ENTER 

REMOVE 

WRIFEL 


FOR576 

FORUPD 

LEVEL 

STATUS 


D062 


Event 

Scheduling 


REQ 

RET 

RECEIV 

CANCLB 

ENTERS 

TERMIl'! 

DISPOS 


SSTAT 

CUM 

CUMB 


Material  Flow 
Events 


Measuring 
u Performance 


OUT 

OUTCST 

ITRSLT 

PLOTR 


Reporting  Results 


Demand  and 
Serviceable 
Returns 


DEMPAR 

GETREQ 


ZERO 

Getting  Started  INITIAL 

INITEM 


RANDU 

GPS 


Figure  III-l.  Major  INSSIM  Subroutines 


Subroutine 

STATUS 


Function 

Compares 
available 
assets  to  the 
respective 
control 


Description 

This  routine  simulates  the 
management  action  portion  of 
D062  system. 


levels,  and 
initiates 
appropriate 
actions 


Each  of  the  above  routines  contain  logic  describing  the 
computational  formulas  and  management  policies  currently 
used  in  the  D062  system.  In  addition,  these  routines  also 
possess  logic  describing  several  forecasting  and  inventory 
control  procedures  that  have  been  suggested  as  alternatives 
current  methods.  These  alternate  procedures  may  be  siiau- 
lated  by  changing  one  of  the  eight  parameter  cards  that 
specify  the  characteristics  of  a given  simulation  run. 

Hence,  a number  of  alternate  inventory  management  proposals 
may  be  evaluated  by  simply  changing  the  input  specifications 
to  INSSin. 

In  addition  to  the  D062-related  subroutines  described 
above,  several  other  INSSIIl  routines  are  used  to  describe 
significant  events  in  the  flows  of  EOQ  items.  These  events 
and  their  corresponding  subroutines  are  as  follows; 


.1. 
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Routine  Event 

REQ  A requisition  is  received  at  the  depot.  This 

represents  a demand  for  a specific  number  of 
units  of  a particular  EOQ  item.  If  possible, 
the  requisition  is  filled  immediately; 
otherv/isc,  the  I'cquicition  is  backordered 
until  a replenishiivant  order  is  received. 

RET  A number  of  serviceable  units  are  returned 

to  the  supply  system. 

RECEIV  A replenishment  order  is  received  by  the 

supply  system.. 

C/dICLB  A customer  v.’ith  an  outstanding  backorder 

cancels  the  requisition. 

ENTERB  Record  the  current  requisition  as  a bac3c- 

order,  and  insert  it  into  the  backorder  file. 

TER.MIN  Action  is  taken  to  stop  a replenishment 

order  that  has  not  yet  boon  received.  This 
event  is  initiated  V7hcnever  an  item's  asset 
position  exceeds  the  termination  level,  and 
a replenishment  order  is  still  being  processed. 

DISPOS  Assets  in  long  supply  are  disposed  of. 


(Note:  The  routines  CANCLB,  TERIIIN,  and  DISPOS  were  not 

used  in  the  current  study. ) 

Each  of  the  above  routines  perform  bookkeeping  operations 
that  update  the  status  of  on  hand  and  on  order  stocks.  These 
routines  also  post  activity  statistics  that  record  inventory 
system  performance. 

The  methods  for  describing  the  demand  generation  process 
is  a critical  element  in  any  inventory  simulation.  In 
INSSIM,  the  demand  generation  process  is  derived  from  demand 
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and  serviceable  return  histories  for  actual  Air  Force  items. 
Specific  computational  details  are  handled  by  subroutines 
DEMPAR  and  GETRCQ. 

As  v/e  shall  see  belov.’,  a major  input  to  our  study  is  the 
actual  demand  histories  for  a sample  of  EOQ  items  from  the 
EOQ  data  bank.  This  input  defines  the  actual  quarterly 
demands  and  serviceable  returns  for  each  item  for  the  period 
FY  71  through  FY  76,  a total  of  20  quarters  v?orth  of  data. 

In  our  study,  the  first  eight  quarters  of  data  V7ere  used  to 
initialise  the  history  files  needed  in  the  D0S2  usage  rate 
calculations.  The  remaining  12  quarters  of  data  v^ere  used 
to  simulate  demands  in  the  inventory  system. 

The  demand  generation  process  is  constructed  so  that 
within  a particular  quarter,  the  number  of  units  of 
demand  and  the  number  of  serviceable  returns  simulated 
exactly  equals  the  actual  values  from  the  EOQ  data  bank. 
Within  a given  quarter,  specific  requisitions  are  generated 
that  have  the  same  statistical  characteristics  as  current 
USAF  items.  Specifically,  requisition  sizes  are  generated 
according  to  the  probability  distributions  presented  in 
Figure  II-2  of  reference  2. 

As  shov/n  in  Figure  III-l,  a number  of  other  routines  are 


i 


also  used  in  I!JSSIM.  These  routines  are  required  to 
initialize  the  simulation  model,  to  collect  and  summarize 


t in  evnnt  scheduling 


and  other  bool'J'.eopincj  tasks 


routines  individually,  the  following  sections  describe  the 


ultiirate  results  of  these  routine 


inents  and  output  prod\ict 


data  flows  of  the 


Inventory  System  Siraulator.  Run 


pecif ications  are  input 


from  File  05  in  card  format 


input  specif i 


that  are  to  he  siiaulat 


inventory 


current  run,  as  well  as  significant  parameter 


holding  cost,  ordering  costs. 


nd  bounds  on  EOQ 


safety  stocks)  required  by  these  policies.  Other  inpu 


eraoloved , and  tlie 


size  of  the  simulation  run  (e.g 


simulated,  time  duration  for  the  study,  etc.) 


A print 
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hown  in  Figure  III- 3.  (A  detailed  dis 


simulation  run  is 


cussion  of  variables  shov\?n  in  this  figure  is  presented  in 


As  s)iov;n  in  Figure  III-2,  item  demand  and  cost  data  is 


input  through  File  07.  This  file  provides  item  information 


extracted  from  the  KOQ  Data  Bank.  This  file  contains  data 
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defining  tlie  unit  price,  lead  times,  management  codes, 
demands  and  serviceable  returns  associated  with  each  item  to 
bn  simulated. 

Output  products  produced  by  IPSSIH  are  routed  to  files 
06  and  03.  File  03  is  a laagnetic  tape  file.  It  contains 
details  by  quarter  on  the  performance  of  each  item  simu- 
lated. This  file  is  designed  for  su)jsequent  statistical 
analysis  of  the  simulation  results  using  the  SPSS  Statistical 
Package . 

File  06  is  routed  to  the  printer.  If  all  output  options 
are  requested,  this  file  will  contain  a print-bad;  of  all 
input  data,  an  event-by-event  description  of  the  simulation 
process,  and  detailed  plots  and  statistical  suramaries  of 
simulation  results. 

Figures  III-4  through  III-O  illustrate  some  of  the 
performance  sunmiaries  produced  by  INSSI’i.  For  example. 

Figure  III-4  provides  statistics  describing  the  naii\ber  of 
units  on  hand  and  on  order  at  the  end  of  each  sim.ulated 
quarter,  as  well  as  counts  of  the  number  of  units  received 
from  vendor  shipments  and  serviceable  returns.  Figure  III-5 
presents  similar  counts  of  the  number  of  expediting,  rationing, 
disposal,  and  termination  actions  taken  in  the  simulation, 
while  Figure  III-6  presents  data  describing  average  inven- 
tories and  fill  and  backorder  rates.  Finally,  Figure  I1I-7 
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suri\marizes  ordering  actions  using  large  and  snail  purcliasing 
methods,  and  Figure  III-C  plots  on  hand  stocks,  on  order 
stocks  and  backorders  as  a function  of  time. 

In  INSSIM,  all  statistics  are  accumulated  according  to 
three  different  measures;  they  are: 

a.  The  number  of  distinct  federal  stock  numbers  or 

distinct  actions  associated  with  the  current 
event. 

b.  The  quantity  of  units  associated  witJi  the  event. 

c.  The  dollar  value  of  all  units  associated  v/ith  the 

event . 

For  example,  suppose  a replenishment  order  for  12  units 
of  a $10  item  is  placed.  In  this  case,  lilSSIM  records  that 
there  was  one  order  action,  12  units  v/erc  ordered,  and  $120 
was  the  value  of  the  ordeir.  The  results  presented  in 
Figures  III-4  through  III~0  are  all  reported  in  terms  of 
unit  counts.  However,  INSSIM  also  produces  similar  tables 
summarizing  the  action  and  dollar  counts  recorded  in  the 
simulation . 

This  concludes  our  discussion  of  the  Inventory  System 
Simulator.  In  the  next  section,  wo  will  discuss  how  this 
model  was  used  to  evaluate  the  relative  cost-effectiveness 


of  the  alternate  PT-formulas 


OnOEP  * 0 PACKORDERS  ■ 0 AGGecGATE 


-hand  and  on-order  assets  and  backorders  verses  tine 


/ 


CHAPTER  IV 
MAJOR  MODEL  CONCEPTS 

To  understand  the  detailed  program  structure  of  INSSIM, 
the  reader  must  possess  a clear  understanding  of  (a)  the 
methods  used  to  simulate  the  passage  of  time,  (b)  the  events 
that  simulate  significant  inventory  system  transactions,  and 
(c)  the  data  files  that  record  current  system  status  and  that 
measure  simulated  performance.  These  major  elements  are  the 
subject  of  this  chapter. 

The  Timing  Mechanism 

The  basic  modeling  concept  employed  in  INSSIM  is  that  of 
an  "event."  An  event  is  a specific  point  in  time  in  which 
the  state  or  condition  of  the  system  changes  or  potentially 
changes.  For  example,  the  amount  of  stock  on  hand  changes 
if  a requisition  is  received  and  goods  are  shipped  to  fill 
the  demand.  Hence,  receipt  of  a customer  requisition 
is  an  event.  Other  events  that  may  change  the  amount  of 
on  hand  stock  include  delivery  of  a replenishment  order 
by  a vendor  of  the  supply  system  and  the  return  of  serviceable 

assets  from  a customer. 

. * 

The  Future  Events  List 

The  sequencing  of  events  through  time  is  controlled  by 
a Future  Events  List  (FEL) . The  FEL  is  a list  of  all  events 
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scheduled  to  occur  at  some  future  (simulated)  time.  For 
each  event  on  the  list,  the  follov;ing  values  are  recorded. 

JTIME  - The  time  the  event  is  scheduled  to  occur, 

JTYPE  - The  event  type  (code) . 

JFSN  - The  5. tern  number  associated  with  the  event  (if 
applicable) . 

JQTY  - The  quantity  associated  v^^ith  the  event  (if 
applicable) . 

JPRIOR  - For  a requisition  event  (code  = 1) , JPRIOR 
denotes  the  requisition  priority,  where  1 = 
high  priority,  2 = low  priority.  For  other 
event  types,  JPRIOR  has  special  meanings,  as 
discussed  below. 

For  example,  suppose  a high  priority  requisition  (event 
type  1)  for  35  units  of  item  number  6 is  received.  In  this 
case,  JTYPE  = 1,  JFSN  = 6,  JOTY  = 35,  and  JPRIOR  = (high 
priority).  The  method  for  setting  the  tine  variable, 

JTIME,  will  be  discussed  below. 

Structurally,  the  FEL  is  a lin)ced  list  in  ascending  order 
by  scheduled  event  time.  In  such  a list,  new  entries 
to  the  list  are  inserted  in  a previously  unused  data 
storage  location,  and  pointers  are  used  to  indicate  the 
correct  sequencing  of  the  entry  in  the  list.  The  major 
variables  associated  with  this  list  are  shown  in  Table 
IV-1. 

At  the  beginning  of  each  simulation  run,  subroutine 
INFEL  is  called  to  initialize  the  pointers  and  control 
variables  associated  with  the  FEL.  Scheduled  events  are 


TABLE  IV-1. 

Future  Events  List  Vf>riables 
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NFEMAX  = maximum  number  of  entries  on  Future  Events  list 

NENTRy  = number  of  entries  on  the  Future  Events  list 

IL0CFE(J)  = nvunber  of  Jth  unused  data  locations  in  Future 

Events  file. 

K = list  index 

JTIME(K)  = clock  time  of  transaction 

JTyPE(K)  = event  type,  as  defined  in  Table  IV-2 

JP0INT(K)  = pointer  to  next  transaction  in  list 

JFSN(K)  = stock  number  identification* 

JQTY(K)  = quantity  involved* 

JPRI0R(K)  = priority,*  where 

1 high  priority 
JPRI0R  = 2 low  priority 

NFIRST  = location  of  first  transaction  on  chain 

NTIME  = time  of  earliest  transaction  on  list 

NL0C  = location  of  last  transaction  placed  on  the  chain 


NOTE:  If  JTYPE(K)  = 2,  denoting  a receipt  event,  JPRI0R(K) 

contains  the  pointer  to  the  next  most  recent  outstanding 
order  for  the  same  FSN,  if  any. 


*if  applicable 
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then  entered  and  removed  from  the  Future  Events  List  by 
subroutines  ENTER  and  REMOVE,  respectively.  New  events 
are  inserted  into  the  FEL  by  the  following  CALL  statement: 

CALL  ENTER  (ITIME,  ITYPE,  IP3 , IP4 , IPS) 
where 

ITIME  = scheduled  time  for  the  event  to  occur. 

ITYPE  = event  type  (code) 

IP3,  IP4 , IPS  = event  parameters — to  be  defined  below — 
that  vary  by  event  type. 

When  subroutine  ENTER  is  called,  the  ne\i  data  is  recorded, 

t 

and  the  list  pointers  are  vipdated  to  insert  the  new  event  in 
the  proper  time  sequence. 

Events  are  removed  from  the  Future  Events  List  by  sub- 
routine REMOVE;  the  CALL  statement  takes  the  form 

CALL  REMOVE  (ITIME,  ITYPE,  IP3,  IP4 , IPS) 

and  the  calling  parameters  are  as  defined  above.  Subroutine 
REMOVE  removes  the  first  entry  from  the  FEL  and  updates  the 
pointers  accordingly;  that  is,  it  delates  the  list  entry 
with  the  smallest  (earliest)  scheduled  clock  time  from  the 
FEL,  and  returns  the  corresponding  data  values  through  the 
parameter  list. 

Subroutine  WRIFEL  is  another  routine  associated  with  the 
Future  Events  List.  In  debugging  new  INSSIM  models,  it  is 
sometimes  desirable  to  write  out  the  entire  Future  Events 
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List  at  selected  times  within  a siraulation  run.  Subroutine 
WRIFEL  fulfills  this  function. 

Timing  Conventions 

To  simplify  programming  and  analysis  tasks,  it  v;as 
desirable  to  establish  tim.ing  conventions  that  differ  slightly 
from  values  associated  with  the  Gregorian  calendar. 

Specifically,  lESSIII  assumes  that  each  day  consists  of 
100  Time  Units  (TU) . Lays,  weeks,  months,  and  years  are 
then  assumed  to  be  related  as  shovm  in  Table  IV-2.  Since 
the  values  are  used  repeatedly  throughout  a sirr.ulation 
run,  specific  COIL-JOE  variables  are  established  for  each 
of  these  time  units.  These  variables  are  also  shown  in 
Tcible  IV-2.  Values  of  these  variables  are  initialized  by 
subroutine  IMITAL  at  the  beginning  of  each  IKS3IK  sim.ula- 
tion  run. 

INSSIV.  Events 

In  the  Inventory  System  Simulator,  three  categories  of 
events  are  used  to  simulate  the  EOQ  Buy  Computation  System. 
They  are : 

a.  Material  flow  events  - describing  the  receipt  of  a 
customer  requisition,  delivery  of  a replenishment 
order,  or  the  return  of  serviceable  assets. 
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TABLE  IV-2,  Time  Conventions* 


Time 

Interval 

Basic 

Value 

Time 

TU 

in 

' s 

INSSIM 

Variable 

1 Day 

100 

TU's 

= 

ITDAY 

1 Week 

7 

Days 

700 

TU's 

= 

I-n^EEK 

1 Month 

4 

Weeks 

2,800 

TU's 

= 

ITMNTH 

1 Quarter 

3 

Months 

8,400 

TU's 

= 

ITQTR 

1 Year 

4 

Quarters 

33,600 

TU's 

= 

ITYEAR 

* It  is  assumed  that  1 Day  = 100  Time  Units  (TU's) , and  each 
INSSIM  Time  Variable  is  expressed  in  TU’s. 
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b.  Management  action  events  - describing  important 
management  decision  points.  The  calculation  of 
control  levels,  status  reviews  to  determine  what 
reorder,  termination,  or  disposal  actions  are 
appropriate,  and  the  establishment  of  budgets  and 
procurement  guidelines  are  examples  of  these  events. 

c.  Simulation  bookkeeping  events  - events  to  collect 
time-valued  statistics,  to  generate  demand  and 
serviceable  returns,  and  to  signal  the  end  of  the 
simulation. 

At  present,  thirteen  possible  events  are  included  in  the 
INSSIM  model.  These  events  are  listed  in  Table  IV-3.  In 
INSSIM,  there  is  a separate  FORTRAII  subroutine  i-o  describe 
how  each  event  changes  the  state  of  the  system,  and  to  record 
associated  performance  statistics.  Table  IV-3  also  presents 
the  subroutines  associated  v;ith  each  event  and  the  defini- 
tions of  the  IP3,  IP4 , and  IPS  parameters  used  in  calling 
subroutines  ENTER  and  REMOVE. 

All  INSSIM  events  may  be  classified  as  either  (a)  scheduled 
events,  (b)  random  events,  or  (c)  dependent  events.  Scheduled 
events  are  events  with  a specific  schedule  of  occurrence  times. 
For  example,  inventory  status  reviews  (event  type  5)  occur 
at  the  end  of  every  week,  and  the  History  File  Update 
event  (event  type  9)  occurs  at  the  end  of  every  quarter. 

On  the  other  hand,  customer  requisitions  (event  type  1)  and 
serviceable  returns  (event  type  4)  are  random  events — the 
time  of  occurrence  of  these  events  is  not  known  in  advance. 
Finally,  the  delivery  of  a replenishment  order  (event  type  2) 
is  a dependent  event  since  the  time  of  delivery  is  dependent 


TABLE  IV-3.  INSSIM  Events 


Event 

Event 

Event 

Subroutine 

Parameters 

IP3 

IP4 

IPS 

1 

Requisition 

REQ 

N 

QTY 

Priority 

2 

Receipt  of  Replenishment 
Order 

RECEIV 

N 

W 

pointer 

3 

Cancellation 

CANCEL 

N 

•t 

4 

Serviceable  Return 

RET 

N 

n 

5 

Inv  Status  Review 

STATUS 

6 

Levels  Computation 

LEVEL 

7 

Buy  Guidelines 

GUIDE 

8 

Budget  Review 

BUDGET 

9 

Update  History  File 

FORUPD 

10 

End  of  Run 

OUTPUT 

11 

Special  Statistics 

SSTAT 

KEND 

12 

Generate  Requisitions  and 
Returns 

DEMPAR 

13 

Trace 

MAIN 

where 


N = item  number 

QTY  = quantity  associated  with  this  event 
KEND  = week  number  within  the  current  quarter 
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upon  earlier  management  reordering  decisions.  Dependent 
events  are  caused  by  the  occurrence  of  an  associated 
random  or  scheduled  event. 

In  INSSIM,  the  first  occurrence  of  each  scheduled 
event  is  created  by  subroutine  INITAL;  that  is,  INITAL 
puts  an  entry  on  the  Future  Events  List  for  each  scheduled 
event  at  the  beginning  of  a simulation  run.  Subsequent 
scheduled  events  are  put  on  the  Future  Events  List  each 
time  a new  scheduled  event  occurs.  For  example,  at  the 
conclusion  of  a status  review  event  (event  type  5) , a 
subsequent  type  5 event  is  scheduled  to  occur  one  week  in 
the  future. 

Specific  values  for  the  time  between  scheduled  events 
are  set  in  subroutine  INITAL.  Table  IV-4  defines 
specific  time  variables  initialized  in  this  routine. 

At  present,  receipt  of  a customer  requisition  and  of 
serviceable  returns  (event  types  1 and  4)  are  the  only 
random  events  simulated  in  INSSIM.  These  events  are 
scheduled  by  subroutine  DEMPAR.  The  process  for  accomplish- 
ing this  is  discussed  in  detail  in  Chapter  VI. 


TABLE  TV-4.  TIMING  VARIABLES  Established  in  INITAL 


l 
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Variable 

IQTRND 

ITINV 

ITIME 


, ITLEVL 

IDLEVL 

ITDIV 

IDDIV 

IITFOR 

IDFOR 

^ ITHQ 

IDTHQ 

i 

I STOP 
ISTAT 
IDSTAT 
INQTR 
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Definition 

clock  time  that  marks  end  of  current  quarter 
number  of  current  quarter 

current  simulation  clock  time  (100  Time  Units  = 1 day) . 

At  the  beginning  of  a simulation  run,  ITIME  = 0. 

clock  time  oJ  the  next  computation  of  stock  levels 

time  interval  between  stock  level  computation 

clock  time  of  the  next  division  level  review 

time  interval  between  division  level  reviews 

time  of  the  next  update  of  demand  history  records 
(Event  type  9 ) 

time  between  history  file  updates 

time  of  next  Headquarters  USAF  stock  fund  budget  review 
time  between  Headquarters  USAF  budget  reviews 
clock  time  that  simulation  is  to  be  stopped 
clock  time  for  activating  statistics  collection  routines 

I 

time  interval  betv/een  statistics  collection  || 

number  of  quarters  to  be  simulated  || 
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An  Illustration 

Figure  IV-1  illustrates  the  interaction  of  the  E’'?'T'EI<  and 
REMU\t:  routines  in  the  nanagemcnt  of  data  in  the  Future  Events 
List.  As  noted  above,  at  the  beginning  of  an  IMSSI’l  run, 
scheduled  events  are  entered  onto  the  rUL  by  subroutine  IMITAL. 
Figure  IV-1 (a)  illustrates  data  stored  on  the  ILL  at  this  time. 
At  the  beginning  of  the  simulation  run,  the  simulated  clock  time 
(ITIME)  is  set  to  zero,  and  seven  events  are  placed  on  the 
Future  Events  List.  Note  that  a type  S (JTYPn  = 5)  event  is 
scheduled  to  occur  at  time  4 0 (JTIJIE  = 40)  . Eext,  a type  G 
event  is  inserted  on  the  FEL  to  occur  at  time  30.  Event  typos 
11,  10,  9,  12,  and  13  are  also  placed  on  the  ELL  by  subroutine 
IKITAL. 

The  variable  NFIRST  identifies  the  storage  location  of  the 
most  imminent  event  on  the  Future  Events  List;  that  is,  the 
event  with  the  lowest  scheduled  event  time.  The  variable  NEhTRY 
identifies  the  total  number  of  events  on  the  Future  Events  List 
at  the  current  time,  v/hile  the  variable  NTII-LE  specifies  the 
clock  time  associated  with  this  most  imminent  event. 

As  noted  above,  subroutine  WP.IFEL  may  be  called  to  print 
the  entire  contents  of  the  Future  Events  List.  Figure  IV-l(b) 
illustrates  the  output  of  WRIFEL  at  the  beginning  of  the 
simulation  run  associated  v;ith  the  data  presented  in  Figure 
IV-l(a).  Note  that  at  this  time,  there  are  seven  entries  or. 
the  Future  Events  List  (NENTF.Y  = 7)  , and  the  most  imminent  of 
these  events  is  the  seventh  entry  in  the  FEL  (NFIRST  = 7) . 
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Figure  IV— 1.  Event  Routine  Interactions 


row  number  in  the  FEL  in  which  the  current  line  of  data  is  stored 
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Figure  IV-l(c)  illustrates  the  initial  events  that  occur 
at  the  beginning  of  the  INSSIM  simulation  run  associated  with 
the  data  given  in  IV-Ka).  Note  that  at  time  = 0 (ITItlE  = 0) 
a type  13  event  (KTYPE  = 13)  is  removed  from  the  Future  Events 
List.  As  shown  in  Table  IV-3,  a type  13  event  causes  on-hand 
and  on-order  stock  status  information  to  be  recorded  for  later 
plotting  by  the  MAIN  routine.  This  event  also  causes  another 
type  13  event  to  be  scheduled  to  occur  one  v;eek  (i.e.  , 70'} 
time  units)  in  the  future.  This  scheduling  is  indicated,  by 
the  second  line  of  Figure  IV-l(c).  The  next  event  on  the 
Future  Events  List  is  a type  C event.  T)iis  event  is  removed 
at  tine  30  (ITIME  = 30).  As  shov/n  in  Table  IV-3,  a typo  G event 
causes  subroutine  LEVEIi  to  be  called  to  compute  levels  for  all 
items  being  simulated.  i'Jhen  this  is  corupleted,  another  levels 
computation  is  scheduled  to  occur  at  time  1430  by  placing  a 
type  6 event  on  the  Future  Events  List.  Finally,  Figure  IV-l(c) 
indicates  that  a type  5 event  is  removed  from,  the  Future  Events 
List  at  clock  time  40.  A type  5 event  causes  subroutine  STAiT'JS 
to  be  called  to  initiate  a status  review  of  the  on-hand  and 
on-order  stocks  of  each  inventory  item.  After  the  status  review 
is  completed,  another  status  review  event  would  be  placed  on 
the  Future  Events  List. 

The  process  illustrated  above  is  then  continued  repeatedly 
throughout  the  simulation.  Required  simulation  events  are 
. placed  on  the  Future  Events  List  by  subroutine  ENTER,  and 

are  subsequently  removed  from  this  list  at  the  appropriate 
scheduled  time  by  su)a routine  REMOVE. 
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DATA  FILES 

A large  number  of  data  elements  are  required  to  operate 
any  computer  simulation  model,  and  INSSiy.  is  no  exception. 

The  major  categories  of  data  associated  with  INSSIil  are 
illustrated  in  figure  IV-2.  As  shovm  in  the  figure,  I13SSI!! 
data  elements  may  be  logically  classified  into  one  of  the 
following  files; 

1.  System  Characteristics  File 

2.  Item  Data  File 

3.  Backorder  File 

4.  Demand  Driver  File 

5.  Perforrrance  Statistics  File 

6.  Simulation  Counters  and  Flags  File 

Let  us  now  consider  the  contents  of  each  of  those  files. 

SYSTEM  CHARACTERISTICS  FILE 

The  Systems  Characteric  File  contains  data  elements  that 
define  the  system  as  a whole.  The  number  of  items  managed  by 
this  system  in  a single  simulation  run,  the  cost  of  processing 
orders  using  small  purchase  and  advertised  procurement 
methods,  and  levels  computation  codes  are  examples  of  data 
elements  in  this  file.  This  information  is  provided  primarily 
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through  inputs  of  file  05.  Specific  data  elements  input 
through  this  file  will  be  discussed  in  detail  in  chapter  VII. 

ITEM  DATA  FILE 

The  item  data  file  contains  information  specifically 
related  to  each  item  being  simulated.  An  item's  unit  cost, 
its  current  level  of  on-hand  and  on-order  stocks,  and  control 
levels  (e.g.,  ROL,  termination  level,  or  retention  level)  are 
examples  of  this  type  of  data  element.  Table  IV-5  presents 
a detailed  list  of  information  items  which  are  contained  in 
this  file.  As  shown  in  table  IV-5,  the  item  data  file  contains 
several  subcategories  of  information.  These  define  (a)  specific 
physical  and  management "characteristics  of  the  item,  (b) 
data  describing  the  stock  status  of  the  item,  (c)  variables 
describing  the  demand  history  for  the  item,  (d)  forecast  vari- 
ables v;hich  quantify  forecast  usage  rates  and  demand  vari- 
ability and  (e)  control  levels  used  in  the  management  of  the 
item's  inventories. 
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Table  IV-5.  Item  Data  File  Variables 


ITEM  CHARACTERISTICS 


Variable 


Definition 


N 

NITEM 

ALC 

FSN 


Item  Index 

Number  of  items  simulated 

Air  Logistics  Center  that  manages 

this  item 

Federal  Stock  Number,  where 


UM 

NOUN 

MGTCD 


FSN(l)  = Jlaterial  Management  Code 
FSN  (2)  = Federal  Stock  Class 
FSN (3)  = First  six  characters  of  NIIN 
FSN (4)  = Remaining  characters  of  NIIN 

Unit  of  measure 
Item  name 

Item  Management  Codes,  where 


UCOST(N) 

LTADM(N) 

ITEM  STOCK  STATUS 

INVACT(N) 

INVDUE(N) 

NBOIU(N) 

NBOIR(N) 

NBOTR(N) 

NBOTU(N) 

NORDPT  (N)  * 

NBOPT(N) * 


MGTCD (1)  = Essentiality  code 
MGTCD (2)  = Supply  management  grouping 
MGTCG(3)  = Weapon  system  code 
MGTCD (4)  = Type  computation  code 

Unit  cost  (dollars) 

Administrative  lead  time  (months) 


Actual  inventory  on  hand  (units) 
Inventory  due-in  from  supplier  (units) 
Priority  I backorders,  in  units 
Priority  I requisitions  backordered 
Total  requisistions  backordered,  all 
priorities 

Total  backorders,  all  priorities, 
in  units 

Pointer  to  most  recent  outstanding 
order 

Pointer  to  oldest,  highest  priority 
backorder 


*Note:  By  convention,  pointers  are  set  to  zero  if  there  are 

no  other  elements  in  the  data  chain. 
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Table  IV-5.  Item  Data  File  Variables 


HISTORY  VARIABLES 


(Continued) 


NDHIS 


NDENT(N) 


NDEMAC(N) 


NDEMND(N,  I) 
NREQ(N) 


Number  of  periods  saved  in 
history  file 

Number  of  forecast  periods  since 
item  entered  system  (negative  values 
indicated  item  has' not  yet  entered 
system) 

Counter  to  accumulate  demand  for  13 th 
item  during  the  current  forecast 
update  period. 

Demand  for  item  M during  Ith  past 
period,  1=1,  2,....,  NDHIS 
Counter  to  accumulate  the  number 
of  requisitions  for  item  N during 
the  current  period. 


FORECAST  VARIABLES 


ADR(N) 


RUE  AN  (N) 

RTREND(N) 

RMAD(N) 

PERSUM(N) 

KNT(N) 

RSIGLT(N) 

REQSIZ (N) 

REQMAD(N) 


Net  annual  demand  rate  for  item  N 
the  net  rate  of  unit  demands  less 
servicable  returns. 

Estimate  of  demand  during  next 
demand  period. 

Estimate  of  trend  in  demand  per 
period. 

Standard  deviation  of  lead  time 
demand 

Sum  of  past  forecast  errors 
Counter  used  for  adaptive  smoothing 
forecasts 

Estimate  of  standard  deviation  of 
lead  time  demand 

Estimate  of  mean  requisition  size 
for  item  N. 

mean  absolute  deviation  of  requisition 
size  for  item  N. 


CONTROL  LEVELS 


IROL(N) 
IRQTY(N) 
ISUL(N) 
IRL (N) 
ITL(N) 


Reorder  level 
Reorder  quantity 
Support  level 
Retention  level 
Termination  level 
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BACKORDER  FILE 

The  backorder  file  records  all  outstanding  backorders  in 
the  inventory  system  at  a given  point  in  time.  This  file 
contains  a record  for  each  requisition  in  a backorder  status. 
Specific  data  elements  in  this  file  are  defined  in  Table 
IV-6.  Included  in  these  data  elements  are  the  item  number 
associated  v;ith  the  backorder,  the  backorder  quantity  and 
priority,  and  the  time  the  item  was  backordered.  A pointer 
system  is  used  to  relate  entries  in  the  backorder  file  v/ith 
the  specific  items  associated  with  that  backorder.  These 
pointer  variables  are  also  defined  in  table  IV-6. 


DEMAND  DRIVER  FILE 

The  demand  driver  file  contains  data  elements  required  to 
generate  the  demands  and  serviceable  returns  that  drive  the 
inventory  system.  The  number  of  requisitions  and  the  asso- 
ciated units  per  quarter  and  the  number  of  serviceable 
returns  to  be  generated  each  quarter  are  examples  of  data 
elements  in  this  file.  Table  IV-7  defines  specific  variables 
associated  with  the  demand  driver  file. 


ITMBAC(J)  simulated  clock  time  that  the  Jth  entry. 

in  the  backorder  file  v/as  placed  into  the 
file 

IDFSNB(J)  item  number  associated  with  the  Jth  back- 

order 

IPRI0R(J)  priority  of  Jth  backorder 

IQTyB(J)  quantity  backordered 

IBACPT(J)  pointer  to  the  file  entry  of  the  next 

backorder  for  this  same  item 

NBMAX  maximum  number  of  entries  in  backorder  file 

IL0CBK(K)  index  of  Kth  unused  data  location  in  back- 

order file 

NL0CBK  number  of  unused  data  locations 


TABLE  IV-7.  DEMAND  DRIVER  FILE 


IDEMI'ID (N, J)  Number  of  units  of  demand  for  item  N 

during  period  J 

IRETUR(N,J)  Number  of  serviceable  Returns  for  item  N 

during  period  J 


IREQ(N,J)  Number  of  requisitions  for  item  N in  period 

J associated  with  the  unit  demands  IDEMND(N,J) 


Subroutine  DEMPAR  is  called  at  the  beginning  of  each 
simulated  quarter.  This  routine  uses  information  in  the 
Demand  Driver  File  to  generate  specific  requisition  and 
serviceable  return  events.  DEMPAR  accomplishes  this  in  such 
a way  that  the  total  requistions  placed  v/ithin  a quarter 
exactly  equal  the  number  of  units  of  demand  v/hich  are  input 
through  the  Demand  Driver  File.  Chapter  VI  discusses  the 
demand  generation  process  in  detail. 


perfor;-iance  statistics  file 

The  Performance  Statistics  File  contains  measures  of  the 
levels  of  activity  observed  during  a simulation  run.  Table 
IV-8  defines  specific  data  elements  contained  in  this  file. 

As  illustrated  in  Table  IV-8,  performance  measures  are  recorded 
in  three  different  units  of  activity.  That  is,  each  type  of 
activity  is  recorded  in  terms  of  (a)  the  number  of  actions  or 
federal  stock  numbers  associated  v/ith  that  activity,  (b)  the 
number  of  units  of  a specific  item  associated  with  that 
activity  and  (c)  the  dollar  value  of  the  nurrfoer  of  units 
associated  with  that  activity  or  action.  For  example,  if  an 
order  is  placed  for  a $10  item  and  21  units  are  purchased  the 
variable  lORDER  (1,1)  would  be  increased  by  1,  since  it  counts 
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TABLE  IV-8.  PERFORMANCE  STATISTICS  FILE 


Variable 


INV0H(I, J) 

INV0R(I,J) 

IRECET(I,J) 

IRETRN(I,J) 

INVDAY(I,J) 

I0RDER(I, J) 

IDISPS(I,J) 

ITERMd,  J) 

IEXPED(I, J) 

IRATON(I,J) 

IREQC(I,J) 

IREQT(I,J) 

IREQKI,  J) 

IBACKT(I,J) 

IBACKI(I,J) 

IBAKDT(I,J) 

IBAKDI(I,J) 

IFILLT(I,J) 


IFILLI(I,J) 

ISHIPT(I,J) 

ISHIPI(I,J) 


Definition 


period  index 


1 actions/FSN 

type  of  nveasure,  where  J = 2 units 

3 dollars 

inventory  on  hand  at  end  of  period 
inventory  on-order  at  end  of  period 
receipts 
returns 

inventory-weeks 
orders  placed 
disposals 

terminations  completed 

expediting  actions 

rationing  actions 

total  requisitions  cancelled 

total  requisitions 

priority  I requisitions 

total  backorders  (end  of  period) 

priority  I backorders  (end  of  period) 

total  backorder  weeks 

priority  I backorder  weeks 

total  fills  (Number  of  requisitions  filled 
immediately  upon  receipt) 

priority  I fills 

total  shipments 

total  priority  I shipments 


rj 


TABLE  IV-8.  (CONT'D) 
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ISMORD(I,J) 
ILGORD(I, J) 
IBOPOH(J) 
IBOPOR(J) 


total  small  orders 
total  large  orders 

On  hand  inventory  at  beginning  of  simulation 
on-order  inventory  at  beginning  of  simulation 
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the  number  of  orders  placed.  The  variable  lORDER  (1.2)  would 
be  increased  by  21  units,  since  this  variable  records  the 
number  of  units  ordered  during  period  I.  Finally,  the  vari- 
able lORDER  (1,3)  would  be  increased  by  210,  since  an  order 
for  21  units  which  cost  $10  each  represents  a total  dollar 
activity  of  $210.  All  of  the  other  performance  measures 
defined  in  table  IV-8  are  updated  in  a similar  manner. 

SIMULATION  COUNTERS  AND  FLAGS 

Every  simulation  model  requires  a series  of  counters  and 
flags  that  are  required  to  control  the  progress  of  the 
simulation,  and  to  perform  necessary  bookkeeping  tasks.  The 
number  of  quarters  to  be  simulated,  the  number  of  the  current 
statistics  collection  interval,  and  the  number  of  simulation 
runs  to  be  performed  are  examples  of  these  types  of  data 
elements.  The  variables  of  the  future  events  list  (FEL) 
defined  in  Table  IV-1  are  an  imiportant  example  of  this 
type  of  data.  Other  major  variables  in  this  category 
are  defined  as  inputs  to  INSSIM  through  File  05.  These  later 
variables  will  be  discussed  in  detail  in  chapter  VII. 
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We  have  now  reviev;ed  the  major  concepts  v/hich  are  the  build- 
ing blocks  of  the  INSSIM  simulation  model.  We've  discussed 

I 

timing  mechanisms  involved  in  the  model  and  the  events  used  to 
represent  inventory  system  activities.  The  data  files  used 
to  describe  the  status  of  the  current  system,  to  drive  the 
simulation  model,  and  to  update  performance  statistics  were 
also  discussed.  In  the  next  chapter,  we  will  discuss  the 
workings  of  the  IIAIN  routine.  This  routine  is  the  primary 
INSSIM  routine,  in  that  it  weaves  all  of  the  major  concepts 
discussed  here  into  a working  model  of  a single  location 
inventory  control  system. 


CHAPTER  V 
MAIN  PROGRAM 


The  MAIN  program  is  the  work  horse  of  the  Inventory 
System  Simulator.  This  routine  is  responsible  for  the 
control  of  input  data,  initialization  of  status  and 
performance  variables,  the  scheduling  of  simulation  events, 
and  the  control  of  output  products.  An  understanding  of  this 
routine  is  essential  for  those  who  desire  to  enhance  the 
current  system. 

A general  outline  of  the  MAIN  program  is  presented  in 
Figure  V-1.  As  shown  in  the  figure,  the  initial  portion 
of  MAIN  is  concerned  with  initializing  the  statistical 
accumulators  and  status  variables  maintained  by  the  system, 
and  in  initializing  the  Future  Events  List. 

After  initialization,  MAIN  controls  the  scheduling  of 
simulated  events,  and  the  calling  of  associated  event 
subroutines.  To  do  this,  subroutine  REMOVE  is  used  to 
remove  the  most  imminent  event  from  the  Future  Events  List. 

This  event  is  called  the  "current"  event.  The  program 
then  branches  based  on  the  event  code  of  the  current  event. 

As  shown  in  Figure  V-1,  separate  subroutines  are  used 
to  perform  bookkeeping  functions  associated  with  each 
event  type.  For  example,  event  type  1 represents  a 
customer  requisition.  When  a type  1 event  is  removed 
from  the  Future  Events  List,  subroutine  REQ  is  called 
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Figure  V-1 


General  Outline  of  MAIN  Program 
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to  perform  the  associated  bookkeeping  tasks.  Similarly, 
for  event  types  2 and  3,  subroutines  RECEIVE  and  CANCLB, 
respectively,  are  called. 

The  event  subroutines  may  in  turn  call  other  routines 
to  assist  in  the  update  calculations.  For  example, 
subroutine  STATUS  is  called  to  simulate  the  occurrence 
of  an  inventory  status  review  (event  type  5)  . This 
routine  in  turn  calls  subroutine  STATN  to  determine 
appropriate  management  actions  associated  with  a given 
item  N.  If  appropriate,  STATN  may  in  turn  call  the 
routines  ORDER,  TERillN,  or  DISPOS  to  represent  procure- 
ment, contract  termination,  or  disposal  actions,  respectively. 

Event  type  10  denotes  the  end  of  the  simulation  run. 

When  this  type  of  event  is  removed  from  the  Future 
Events  List,  one  or  more  output  routines  may  be  called. 
Specific  output  products  produced  are  specified  by  param- 
eters which  are  input  through  File  05.  A detailed  discussion 
of  these  control  parameters  is  presented  in  Chapter  VII. 

If  detailed  simulation  results  by  item  are  to  be  produced, 
subroutine  ITRSLT  is  called.  If  tabular  summaries  are 
desired,  subroutines  OUT  and  OUTCST  are  called.  If  plots 
of  important  inventory  characteristics  are  desired, 
subroutine  PLOTR  is  called.  Finally,  an  optional  abbre- 
viated performance  report  may  be  requested  that  is  useful 
In  the  debugging  of  INSSIM  enhancements. 


A detailed  flow  chart  of  the  MAIN  program  is  presented 
in  Figure  V-2.  As  shown  in  the  figure,  liAIN  first  sets 
several  management  parameters  that  are  used  if  alternate 
levels  calculations  are  not  specified.  Definitions  for 
the  variables  GTLF,  GRLF,  GSULF,  and  GSLF  shown  in  Figure 
V-2  are  presented  in  Table  V-1.  These  values  are  used 
in  levels  calculations  performed  by  subroutine  LEVELN. 

After  initializing  the  above  variables,  MAIN  reads  simula- 
tion run  parameters  specified  in  File  05.  These  inputs 
are  discussed  in  detail  in  Chapter  VII.  The  "run"  loop 
then  begins.  An  input  parameter,  NRUN,  specifies  the 
number  of  distinct  simulation  runs  to  be  performed.  The 
variable  CSHORT(K),  which  is  provided  as  input  in  File  05, 
specifies  the  value  of  the  Lagrange  multiplier  to  be 
used  in  the  Kth  simulation  run.  Hence,  the  value  of  the 
variable  CSHORT  is  set  to  the  appropriate  value  for  use 
in  the  current  simulation  run. 

Next,  MAIN  initializes  the  random  number  stream,  rewinds 
the  item  data  file  (File  07) , emd  zeros  the  statistical 
accumulators  arrays. 

Subroutine  INITAL  is  now  called  to  initialize  the 
time  parameters  associated  with  the  simulation  run,  and 
to  create  the  initial  scheduled  events  by  putting  them 
on  the  Future  Events  List.  Subroutine  IMITEM  is  then 
called  to  read  in  input  data  for  the  NITEM  items  that  are 
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= MRUN  + 1 


Set  Default  Management  Parameters 
GTLF  = 24. 

GRLF  = 12. 

GSULF  = 0. 

GSLF  = 1. 


Read  Simulation  Run  Parameters  from 
File  05 

(if  there  is  no  more  data,  stop) 


Begin  Run  Loop 
MEUN  = 1 


Set  shortage  cost  parameter  for  this  run 
COSHRT  = CSHORT  (MRUN) 


Initialize  Random  Number  Stream 
R = RAIIDU  (-.1) 


Rewind  Item  Data  File 
REWIND  INLU 


Zero  Statistics  Arrays 
CALL  ZERO 


Begin  Replication  Loop 
KREPL  = 1 


15  MKREPL  = KREPL  + 1 


Initialize  Time  Parameters  and  Create 
Initial  Events 

CALL  INITIAL 


Read  in  Data  for  NITEM  Items,  from  File  0?, 
Initialize  Beginning-of-Period  Statistics 

CALL  INITEM 


Figure  V-2,  The  MAIN  Program. 


Remove  Next  E-/ent  from  the  Future  Events  Hot 
and  Branch  hy  Type  of  Event  (XTfPE). 

CALL  REMOVE  (TDE,  XTYPE,  IP3,  ipl»,  IP5) 


Program,  continued. 
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TABLE  V-1 

DEFAULT  VALUES  FOR  LEVELS  CALCULATIONS 


Varictble 

GSLF 

GROQF 

GTLF 

GRLF 

GSULF 

GE0QF(I) 


Definition 

safety  level  factor  (in  months) 

order  quantity  factor  (in  months) 

termination  level  factor  (in  months) 

retention  level  factor  (in  months) 

support  level  factor  (in  months) 

order  quantity  factor  for  Ith  demand  rate  class 


Formulas 

MR  = monthly  demand  rate  in  units 

lead  time  requirement  RLT  = (admin  + prod 


safety  level  SL 
reorder  quantity  ROQ 
reorder  level  ROL 
termination  level  TL 
retention  level  RL 
support  level  SUL 


GSLP*MR 

GROQF*GEOQF(I) *MR 
= RLT+SL+ 

= ROL+GTLF*MR 
= TL+GRLF*MR 
= GSULF* RLT 


lead 


time) *MR 


( 
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to  be  included  in  the  current  simulation  replication. 

This  data  is  read  in  from  File  07. 

Simulation  of  specific  inventory  events  now  begins. 
Subroutine  REMOVE  is  called  to  remove  the  most  imminent 
event  from  the  Future  Events  List,  and  MAIN  then  branches 
based  on  the  event  code  of  this  event.  Figure  V-2  specifies 
the  specific  subroutines  that  are  called  during  this 
stage  of  processing.  Detailed  narratives  describing  each 
of  these  programs  are  contained  in  Volume  II  of  this 
report. 

Observe  that  when  a type  10  event  occurs,  the  variable 
KREPL  is  checked  to  see  if  the  replication  count  exceeds 
NREPL,  the  number  of  replications  specified  for  the  current 
simulation  rvn.  If  not,  KREPL  is  increased  by  one,  the 
program  returns  to  block  15  to  read  in  a new  set  of  item 
data  and  to  perform  another  replication  of  the  simulation. 
If,  on  the  other  hand,  KREPL  equals'  NREPL,  simulation  run 
statistics  are  produced.  If  the  output  control  parameters 
lOUT  equals  one,  subroutines  OUT  and  OUTCST  are  called  to 
present  tabular  summaries  of  the  aggregate  performance 
statistics  observed  during  the  NREPL  replications  of  the 
simulation  experiment.  If  IGRAPH  equals  one,  subroutine 
PLOTR  is  called  to  produce  graphical  results.  If  IPUNCH 
equals  one,  the  abbreviated  statistical  svunmary  is 


written  from  MAIN 
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After  output  products  are  produced,  MAIN  tests  to 
find  if  all  requested  runs  have  been  performed.  If  so, 
the  simulation  stops.  Otherwise,  MAIN  returns  to  statement 

I 

number  12.  The  run  counter,  MRUN,  is  then  incremented, 
the  shortage  cost  parameter  COSHRT  is  reset  to  the  new 
Lagrange  multiplier  value,  and  the  initialization  process 
begins  again.  The  sequence  of  initialization,  simulation, 
and  output  operations  is  repeated  until  all  requested 
simulation  runs  are  performed. 
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CHAPTER  VI 

1 

I 

THE  DEMAND  GENERATION  PROCESS  | 

An  important  feature  in  the  development  of  any  simula- 
tion model  is  the  method  for  representing  customer  demands.  : 

In  our  model,  actual  usage  history  for  EOQ  items  was  used  as 
the  basis  for  the  demand  generation  process.  These  histories 
contain  the  number  of  units  that  were  demanded  by  quarter 
since  fiscal  year  1971.  Unfortunately,  detailed  historical 
information  on  the  nature  of  specific  requisitions  placed  for 
each  item  was  not  recorded.  Consequently,  it  was  necessary 
to  develop  a method  for  describing  the  requisition  generation 
process  using  the  recorded  quarterly  usage  history  as  a 
starting  point. 

In  developing  the  demand  generation  process,  we  relied 
heavily  on  the  statistical  results  discussed  in  Section  II  of 
reference  2.  The  distribution  of  average  requisition  size  '■ 

was  a primary  result  of  that  section.  This  distribution  is 

reproduced  in  Figure  VI-1.  , 

' 1 

A flow  chart  of  the  steps  used  to  generate  requisition 
sizes  with  the  same  statistical  characteristics  as  shown  in 
Figure  VI-1  is  presented  in  Figure  VI-2. 

As  shown  in  the  figure,  the  demand  generation  process 
begins  by  considering  the  number  of  units,  D,  that  were 
demanded  in  a given  historical  quarter.  We  next  determined 
the  demand  class  associated  with  this  particular  level  of 


demand.  Once  the  appropriate  demand  class  is  identified, 
a Monte  Carlo  process  is  employed  to  simulate  the  specific 
number  and  size  of  requisitions  associated  with  a total 
demand  of  D units.  Block  C of  Figure  VI-2  illustrates  the 
major  steps  in  the  Monte  Carlo  process.  The  procedure 
begins  by  determining  a random  number  X which  is  uniformly 
distributed  on  the  interval  between  0 and  1.  This  is 
conceptually  equivalent  to  selecting  a random  percentile 
from  the  cumulative  probability  distribution  of  average 
requisition  size.  Next,  the  cumulative  probability  distribu- 
tion illustrated  in  Figure  VI-1  was  used  to  determine  the 
specific  requisition  size  R associated  with  the  random 
percentile  X.  This  was  our  tentative  value  for  the  first 
requisition  to  be  generated.  We  then  check  if  the  total 
cumulative  units  generated  so  far  exceeds  D units.  If  the 
cumulative  units  is  less  than  D,  the  requisition  generation 
process  continues  as  described  above.  On  the  other  hand,  if 
the  cumulative  units  exceeds  D,  the  last  requisition  is 
reduced.  This  is  to  ensure  that  the  total  number  of  units 
requisitioned  throughout  the  period  exactly  equals  the  amount 
D recorded  in  the  item  history  record. 

The  above  process  determines  a set  of  requisitions  whose 
total  units  equal  the  total  demand  recorded  in  the  item 
history  record.  To  determine  the  time  of  arrival  of  each 
requisition,  it  is  assumed  that  arrival  times  were  uniformly 


distributed  throughout  the  quarter.  A Monte  Carlo  process 
is  then  used  to  determine  the  specific  arrival  time  for  each 
requisition  generated.  This  is  equivalent  to  assuming  that 
the  time  between  arrivals  is  exponentially  distributed  within 
a quarter. 

To  implement  the  above  logic,  subroutine  DEMPAR  is  called 
at  the  beginning  of  each  simulated  quarter.  Subroutine 
GETREQ  is  then  called  by  DEMPAR  to  determine  specific  requisi- 
tioi  sizes  using  the  logic  defined  in  Figure  VI-2.  DEMPAR 
then  places  a type  1 (requisition)  event  on  the  Future  Events 
List  (FEL)  for  each  generated  requisition.  Finally,  DEMPAR 
places  a type  13  event  on  the  FEL  to  occur  one  quarter  in 
the  future.  This  type  13  event  triggers  the  next  call  to 


DEMPAR 
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Given  D,  the  number  of  units 
dennndecl  in  the  current  ouarter 


Uetemino  demand  class  associate, 
v/ith  D,  using  Table  V-1 . 


Set  j=l 
and 


Determine  R j , the  size  of  requisition 
j,  by  performing  the  following  steps: 


a.  Determine  a random  numl^er  X 
uniformly  distributed  on  the 
interval  0.  to  1.0. 


b.  Use  Pigure  II-5  to  determine 

R,  the  requisition  size  associated 
with  tJie  random  percentile  X. 


c.  Set  Rj=p. 


Record  the  cumulative  units 
generated  so  far,  i.e.  set 
TR=TR+Rj 


If  the  total  units  requisitioned 
so  far  exceeds  D,  reduce  Rj  so  th.at 
the  total  units  just  equals  D,  i.e. 
If  TP>D,  set  Rj=Rj-TR-;:)) 


Determine  time  of  arrival  for  reejuisition  j 
assuming  arrival  times  are  uniformly  distri- 
buted throughout  the  quarter.  , 


Is  the  total  demand  generated 
less  than  D? 


End  of  Demand  Generation  Process 


Figure  VI-2,  The  Demand  Generation  Process 


CHAPTER  VII.  INPUT  SPECIFICATIONS 


As  illustrated  in  Figure  III- 2,  INSSIM  requires  two 
input  files.  File  05  and  File  07.  File  07  specifies  the 
characteristics  of  each  inventory  item  to  be  simulated, 
while  File  05  specifies  the  number,  size,  and  characteristics 
of  the  simulation  runs  to  be  performed.  Let  us  now  consider 
each  of  these  files  in  detail. 

FILE  05;  SIMULATION  RUN  SPECIFICATIONS 

Eight  different  parameter  cards  are  required  to  specify 
a given  INSSIM  simulation  scenario.  These  cards  provide 
the  following  types  of  data: 


Card 


Contents 

Identification 
Output  Controls 
Debug  Flags 

Input  File  Specifications 
Management  Methods  to  be  Simulated 
Management  Parameters  Required 
by  the  computational  methods  specified 
on  card  5 

System  Cost  Parameters 
Simulation  Size  Specifications 


Figure  VII-1  presents  a print  back  of  a specific  set  of 

File  05  input  data*.  And  this  figure,  labels  on  the  left  liand 

margin  identifies  the  FORTRAN  variables  associated  with  each 

input  parameter,  while  the  specific  numerical  value  assumed 

by  this  variable  is  presented  on  the  right.  Brief  definitions 

of  each  of  these  input  variables  are  presented  in  Table  VII-1. 

♦Inputs  to  File  05  axe  specified  in  free-field  BCD  format.  See  page  C-1, 
Appendix  C for  an  example. 
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Table  VII-1.  Simulation  Run  Parameters  (File  05) 


Card  Type  1.  Run  Identification 

Variable  Definition 


I DENT 

Run  identification  number 

TEXT 

Description  of  the  current  run 
(up  to  40  characters) . The 
description  must  be  included 
in  quote  marks. 

Card 

Type  2 . 

Output  Controls 

ITWRT 

If  ITWRT  = 1,  call  IRSLT  to  write 
detailed  simulation  results  for  each 
item  to  File  08. 

ITOUT 

If  ITOUT  = 1,  call  OUT  and  OUTCST 
to  print  summary  statistics  for 
each  simulation  run. 

IGRAPH 

If  IGRAPH  = 1,  call  PLOTR  to  plot 
on  hand,  on  order,  requisition  and 
backorder  data  verses  time. 

IPUNCH 

• 

If  IPUNCH  = 1,  write  a brief  summary 
from  MAIN  after  each  simulation  run. 

Card 

Type  3 . 

Debug  Flags 

IDEBUG 

If  IDEBUG  = 1,  write  all  entries 
and  removals  from  the  Future  Events 
List. 

lEBUG 

If  lEBUG  = 1,  print  all  item  input 
data  on  File  06. 

IFBUG 

. 

If  IFBUG  = 1,  print  item  forecast 
data  from  FOR576. 

IGBUG 

If  IGBUG  = 1,  write  demand  data 
generated  by  DEMPAR 

IHBUG 

If  IHBUG  = 1,  write  item  levels 
calculations  from  LEVELN. 

Card 

Type  4 , 

Item  Input  File 

Definition 

INLU  Logical  unit  number  of  item  demand 

data  input  file. 

INTYPE  Format  of  item  input  file,  where 

1 « Free-Field  BCD  format, 

2 = Binary  Format 


Card  Type  5.  Inventory  Management  Codes 


Variable 

Definition 

ICDFOR 

Forecast  Formula  Code  used  in 
FOR576  to  estimate  annual  demand 
rate  ADR(N) . 

ICDSIG 

Formula  code  for  estimating  the 
standard  deviation  of  lead  time 
demand  RSIGLT(K)  in  FOR576. 

ICDEOQ 

EOQ  formula  code  used  in  LEVELN. 

ICDSL 

Safety  level  formula  code  used 
in  LEVELN. 

ICDSLL 

Safety  level  limit  code,  used  to 
compute  limits  on  the  safety  level 
in  LEVELN 

ICDBG 

Budget  Guideline  code 

Formula  code  for  forecasting 
serviceable  returns  in  FOR576. 

Card  Type  6.  Management  Parameters 

EOQMIN  Minimum  EOQ,  in  months  supply. 

EOQMAX  Maximum  EOQ,  in  months  of  supply. 

SLMIN  Minimum  safety  level,  in  months 

of  supply. 

SLMAX  Maximum  safety  level,  in  months 

of  supply. 


Card  Type  7.  System  Parmeters 

Cost  of  holding  one  unit  in  inventory 
for  one  year,  expressed  as  a fraction 
of  the  item's  price. 

Implied  shortage  cost.  Four  values 
are  provided  as  input,  for  use  in  up 
to  4 sequential  simulation  runs. 

Cost  of  processing  a "small"  order, 
an  order  whose  dollar  value  is  less 
than  CSTBRK. 

Cost  of  processing  a "large"  order. 
Cost  break-point  used  to  differentiate 
between  large  and  small  order'^. 


COSHLD 

CSH0RT(4) 

COSORD(l) 

C0S0RD(2) 

CSTBRK 


Card  Type  8.  Simulation  Run  Parameters 


NRUN 


The  number  of  simulation  runs  to 
be  performed. 

The  number  of  quarters  to  be  simulated 
in  each  run. 


INQTR 


I 


Variable 


NREPL 


NITEM 


NDHIS 
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Definition 

The  niomber  of  replications  to  be 
perfomed  within  each  simulation  runs. 
The  number  of  items  to  be  simulated 
within  each  replication. 

The  number  of  quarters  of  information 
on  the  item  data  file  to  be  used  to 
initialize  the  simulation  History  File. 
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Let  us  now  consider  each  of  these  input  cards  in  more  detail. 
CARD  1:  RUN  IDENTIFICATION 

This  card  identifies  the  current  simulation  run.  The 
RUN  ID  is  a numerical  identifier  which  is  recorded  the 
detailed  simulation  results  file  08.  This  identifier  makes 
it  possible  to  identify  specific  simulation  runs  using  auto- 
mated post-processing  routines.  The  title  simply  identifies 
in  words  the  type  of  simulation  exercise  being  performed. 

CARDS  2 and  3;  OUTPUT  CONTROLS 

These  two  input  cards  specify  the  types  of  output  products 
which  are  to  be  produced  during  the  simulation  run.  Card  2 
specifies  summary  products  to  be  printed  or  written  to  tape 
files,  while  card  3 specifies  specific  debugging  messages 
that  are  to  be  printed  during  the  conduct  of  the  simula- 
tion. Outputs  specified  by  these  parameters  are  discussed  in 
more  detail  in  the  Chapter  VIII. 

CARD  4;  ITEM  INPUT  FILES 

As  noted  above,  item  data  is  entered  into  INSSIM  through 
File  07.  This  input  may  be  in  one  of  two  different  forms: 

(a)  binary  format  or  (b)  free-field  BCD  format.  Card  4 
specifies  which  of  these  options  is  to  be  employed  in  the 
current  simulation  run.  BCD  format  is  useful  for  the  input 
of  manually  prepared  data  sets  for  testing  of  new  INSSIM 
enhancements.  On  the  other  hand,  binary  input  is  useful  for 
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Table  VII-2 


Variable 

ALC 

FSN 


UCOST 

UM 

NOUN 

MGTCD 


lOH 

lOR 

I PPL 
RIPPPR 

IDEMND  (N,  J) 
IRETUR  (N,  J) 
IREQ  (N,  J) 


Item  Input  Data  (File  07) 


Definition 

Air  Logistics  Center  that  manages  this  item 
Federal  Stock  Numbers,  where 

FSN(l)  = Material  Management  Code 
FSN(2)  = Federal  Stock  Class 
FSN (3)  = First  six  characters  of  the 
National  Item  Identification 
Number  (NIIN) 

FSN (4)  = Remaining  3 characters  of  the 
NIIN 

Unit  Cost  of  item  in  dollars 

Unit  of  Measure  (e,g.  each,  feet,  ounces,  etc.) 
Item  name 

Item  management  codes,  where 

MGTCD (1)  = Essentiality  code 
MGTCD (2)  = Supply  management  grouping 
MGTCD  (3)  = V7eapon  system  code 
MGTCD (4)  = Type  computation  code 

Initial  on-hand  assets  (units) 

Initial  on-order  units  (also  know  as 
"due-ins" ) 

Industrial  Preparedness  Production  Leadtime 
Industrial  Preparedness  Program  Ratio 

Number  of  units  of  demand  for  item 
N during  period  J 

Number  of  serviceable  returns  (units)  for 
items  N in  period  J 

Number  of  requisitions  for  item  N in 
period  J 


VII-8 


production  runs  involving  many  items  and  many  simulation 
replications.  Binary  input  is  useful  in  the  later  case 
because  it  generally  executes  much  more  rapidly  than  jobs 
with  BCD  inputs. 

Appendix  A illustrates  the  format  of  INSSIM  input 
for  binary  runs.  For  binary  runs,  program  DATAB2  is  called 
to  reformat  this  data  to  a binary  equivalent.  Hence,  DATAB2 
serves  as  a preprocessor  for  the  INSSIM  MAIN  program. 

Figure  VII-2  illustrates  a sample  free-field  BCD  input 
file  to  the  model.  Note  the  data  is  input  in  the  same  se- 
quence as  shown  in  Appendix  A for  binary  inputs. 

CARDS  5 AND  6t  MANAGEMENT  METHODS  CARDS 

Together,  cards  5 and  6 specify  the  calcuation 
formulas  to  be  used  in  computing  inventory  control  levels, 
and  specify  specific  parameters  to  be  used  in  these 
calculations.  Subroutines  FOR576  and  LEVELN  perform  the 
forecasting  and  inventory  control  levels  calculations 
specified  by  these  cards. 

The  code  ICDFOR  specifies  the  calculation  to  be  used 
in  computing  inventory  position  in  subroutine  STATN.  Possible 
options  are  defined  in  AFLC/XRS  Working  Paper  No.  73,  by 
R.  J.  Stevens,  March  1974,  and  in  the  COMMENT  Statements  of 
STATN.  To  simulate  current  D062  calculations,  set  ICDFOR  = 1. 


VII-9 


Figure  VII-2.  Sample  BCD  Item  Input  File 

(File  07) 


450$:DATA:07 

A63  SM  12  3A  567893  123  EA  10.03  TLST- 
473  33336666  350  3663366 

480  111110300  1111000 

490  1 1 1 122221  1221  122 

503  SM  11  55  66  77  EA  1.03  TEST2-  ITE!*! 
51 022224444  133  1001  100 
520  0030000000000300 
530  1 1 1 1 2 2 2 2 1 1 0 0 1100 

540ii 

550$  ENDJOB 


ITEM  ABCD001  122 

-»-UNIT  DEMAND 

"RETURNS 

"REQUISITIONS 

HIJK001  123 

"UNIT  DEMAND 
■—RETURNS 
"REQUISITIONS 


NOTE:  For  this  data  set,  these  are  16  periods  of 

demand  history.  Hence,  to  read  this  data. 
Card  4 of  File  05  should  set  INLU  = 7, 
INTYPE  = 1,  and  NDEM  = 16. 
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The  code  ICDSIG  specifies  the  calculation  formulas  to 
be  used  in  computing  average  annual  demand  rates  ADR(N)  and 
the  standard  deviation  of  demand  in  the  lead  time  RSIGLT(N). 
These  calculations  are  performed  by  subroutine  FOR576.  Figure 
VII- 3 presents  the  currently  coded  computational  formulas. 

At  present,  there  are  no  options  to  these  codes;  the  calcula- 
tion specified  in  Figure  VII-3  will  always  be  used. 

In  contrast  to  the  forecasting  formulas,  there  are  several 
options  for  EOQ  and  safety  level  calculations.  These  calcula- 
tions are  performed  by  subroutine  LEVELN,  and  the  codes 
ICDEOQ,  ICDSL,  and  ICDSLL  specify  the  current  computational 
options . 

Subroutine  LEVELN  has  several  distinct  computational 
stages.  The  routine  first  computes  an  economic  order 
quantity  Q according  to  the  formula  specified  by  the  code 
ICDEOQ.  Figure  VII-4  specifies  the  computational  options. 

The  resulting  value  of  Q is  then  limited  to  be  no  less  than 
EOQMIN  months  of  supply  and  no  more  than  EOQMAX  months  of 


supply.  Further,  if  Q is  less  than  1,  Q is  set  equal  to  1. 

With  Q computed,  LEVELN  then  computes  the  safety  level, 
SL,  according  to  tlie  formula  specified  by  the  code  ICDSL. 
Figure  VII-5  specifies  the  current  computational  options. 


I— 
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Figure  VII-3.  Forecast  and  Standard  Deviation 
Calculation  Fori'iulas  used  in 
Subroutine  FOF57G. 


Ouarterlv  Denand  Fate: 


FORCST  = X!  (Gross  Denand  ) - (serviceable  returns  ) 

n = 1 2- 

vrhere  F equals  the  niinher  of  auartors  of  availaV^le  data. 
Annual  Denand  Rate: 

ADF(?I)  = 4.  * FORCST 
Average  Reauisition  Sisc: 


GROSS  Di::!.A!IDS. 


RFOSIZ(!I)  = n = 1 


n 


Z" 

n = 1 


FRDOUDdCirS 


n 


Ouarterly  ?'AD: 


MAD 


Q 


= y jActvtal  Ouarterly  Denand^  - 3 * MDF  j /u 
n = 1 / 


where  D number  of  quarters  of  data 


Standard  Deviation  of  Lead  Tinie  Demand 


SIG  = 0.5945*  r4ADO*  (0.82375  + 0.42625*'  Leadtime  Months) 


f 

i 
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Figure  VII-4.  Order  Ouarterlv  C^^lcula*■ion  Fornula'^ 


LF.T;  O = Order  quarterly 

yOR  = Monthly  der'.anJ  rate  (iinits) 

ADR  = Annual  demand  rate  (unitr. ) 

ADDR  = 7mnual  dollar  demand  rate 
COF)ORD(I)  = cont  to  place;  an  order,  where 

1 = 1 indicates  small  purclrise  and 
1 = 2 indicates  large  purcliase  T;ot’aod:3 
CSTRRK  = Dollar  breakpoint  distinruishirq  laroe  an^ 
small  purchase  methods 

COSI'LO  = Cost  to  hold  one  dollar  od  stock  in  in'^entory 
for  one  ''■ear 
UC  = Item  unit  cost 

Vhe  code  TCDFOO  specifies  t.he  following  for’-ulas. 


I 


\ 

\ 


ICDRQQ  Calculation 

1 If  (ADDR ^ 05, dOO) , O = 3*  r'R 

If  ($1,030  - ADDR  - 15,303)  p O'*  R'y, 
Otherwise  D = ip*  t”; 

2 'dilson  lot  size  formula 


EQO  Size  Limits 

For  the  order  quantity  0 computed  above, 

if  n>r;oo’iAx  *rmr,  set  o = fdouax  * r;lr 

if  0-<-E0n:iiM  *R'.',R,  set  n = ROO’ii’i  * Rin 
if  Q<1,  set  0 = 1 


Figure  VI 1-5 


Safety  Level  Calculation  Forinnlns 


Let  SL  = Safety  level 

RMR  = Monthly  demand  rate  (units) 

RLT  = expected  number  of  demands  in  a load 
tine 

REQSIZ  = Average  requisition  si;:e 

CT  = Standard  deviation  of  demand  in  the  lead  time 
The  code  ICDSL  specifies  the  following  foriiulas. 


ICDSL 

Value  Calculation 


Safety  Level  equals  one  months  suppl'^ 


SL  = 1.*  R’lR 


Safety  level  equals  1/4  of  expected  demand  in 
the  leeid  time 


SL  = .25  * RL'^ 

AFLC’!  57-G  formula  (July  1577) 

a)  Let  7 =/Averaqe  Requisition  Sice  = /Tl^PsTs 

b)  Compute  K, 

/liaolied  \ 


K = 0.707  X jy 


Shortage  j 
Factor 


1 C-  . (l-T'XF  (-/2  FOO/cr)) 


Holdiing  ^ i 
IMCost  \C 


:Jnit 

Cost 


Z /2  FOQ 


c)  Finally,  SL  = K * <X 


Presutti-Trenp  formula  to  minimise  exoected  units 
haejeordered. 


Set  7.  = 1.  Tlien  use  formulas  for  ICPSI.  = 3 
defined  above. 


Presutti-T’repp  formula  to  niniiriice  expected  rottuisitions 
backordered. 


Set  7,  = average  requisition  sice  = RFOSIZ. 
Then  use  formulas  for  ICDSL  = 3. 


described  in  Figure  VII~6,  Briefly,  if  ICDSLL  equals  2, 

SL  is  limited  to  be  no  more  than  SLMIN  months  of  supply, 
and  no  more  than  SLMAX  months  of  supply.  On  the  other  hand, 
if  ICDSLL  equals  1,  SL  is  limited  to  be  no  less  than  SLMIN 
months  of  supply,  as  before,  and  no  more  than  the  lesser 
(a)  three  times  the  standard  deviation  of  lead  time  demand, 
or  (b)  the  expected  demand  in  a lead  time. 

Finally,  the  codes  ICDBG  and  ICDSR  identify  calculations 
to  be  employed  in  setting  budget  guidelines  in  predicting 
future  values  for  serviceable  returns.  These  codes  are  not 
currently  utilized  in  the  INSSIM  model. 


1 


I 

I 
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Figure  Vll-fi.  Safety  Level  Linit  Calculation:! 


Let 


SL  = Safety  level  computed  according  to  one 

of  the  formulas  specified  in  Figure  VI 1-5. 

RMR  = Monthly  demand  rate. 

FL”  = Fxoectod  demand  in  lead  tine. 

SIG  = Standard  deviation  of  lead  time  demand. 

SLMI’T  = "’inimun  r.afet''’  level  in  months  of  suoply. 
SLMAX  = May.inum  safetv  level  in  months  of  supoly. 

The  the  code  ICD3LL  specifies  the  following  limit  calculations. 


ICnSLI, 

Value  Calculation 


1 If  SL  < SLMIM  * Pin,  set  SL  = SLMI'!  * 

If  .SL>  hLT,  set  SL  = FLm 

If  SL>  3*  SIG,  net  SL  = 3 * SIG 

2 If  SL<SL:iIP  * PMR,  set  SL  SLMI'J  * }f'P 
IF  SL  > SL:!AX  * RMR,  set  ST,  SL’IAX  * h'n 


] 

1 
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Figure  VII-7.  Levels  Calculations 
Currentlv  Coded 


Given  the  results  of  the  calculations  defined  in  Figures 
VII-3  through  VII-6,  the  levels  for  item  are  confuted 
as  follov;s,  and  then  rounded  to  the  nearest  integer  value. 


Reorder  Level:  IROL(n)  = RLT  + SL 
Order  Quantity:  IROT(N’)  = Q 

Termination  Level:  ITL(M)  = A var'.'  large  number 
Retention  Level:  IRL(n)  = a very  lare  number 
Support  Level:  ISUL(N)  = 0,' 


This  parameter  card  defines  the  size  as  the  simulation 
exercize  to  be  performed.  The  variable  I-SRUK  defines  the 
specific  number  of  simulation  runs  to  be  accomplished  accord- 
ing to  the  eight  parameter  cards  in  the  current  set.  NRIJN 


t 


cannot  exceed  four.  The  variable  INQTR  defines  the  number  of 


quarters  to  be  simulated,  while  NREPL  defines  the  number  of 


replications  of  the  simulation  (each  for  INOTR  quarters)  to 


be  performed  by  summary  statistics  are  printed.  NITEII 


defines  the  number  of  items  to  be  included  in  a single 


inventory  simulation  replication.  With  present  coding, 


NITEM  should  always  equal  1.  Finally,  NDHIS  defines  the 


number  of  quarters  of  data  provided  as  input  that  are  to  be 


IIDHIS  should  not  exceed  a value  of  8.  In  addition,  the  total 


of  IWOTR  and  ITOHIS  cannot  exceed  the  value  of  NDEIl,  the  total 


number  of  quarters  of  data  provided  as  input  to  the  system 


8 illustrates  the  relation 


lips  among  the 


and  Horn 


case  in  vihich  there  are  24  quarters  of  data  read  as  input 


through  File  07;  that  is,  IIDEM 


Finally,  in  this  example  the  simulation  proceeds  for  12  quarters, 
beginning  v/ith  the  ninth  quarter  of  data  read  from  File  07,  and 


Data  for  quarters  21  through  24 


ending  with  the  -2  0th  quarter 


This  concludes  our  discussion  of  input  parameters  to  the 


IHSSIM  model.  In  the  next  chapter,  we  v/ill  discuss  output 


products  produced  by  the  simulation  model 


CHAPTER  VIII.  OUTPUT  PRODUCTS 

As  discussed  in  Chapter  VII,  specific  output  products 
produced  in  a given  INSSIM  simulation  run  are  specified 
by  input  parameters  defined  on  cards  2 and  3.  There  are 
two  basic  categories  of  outputs:  (a)  summaries  of  sim- 
ulation results,  and  (b)  debugging  aids.  The  latter  cate- 
gory of  outputs  are  particularly  useful  in  the  development 
of  enhancements  to  the  INSSIM  simulation  model.  Let  us 
now  consider  each  of  these  types  of  output  products  in 
more  detail. 

Results  Summaries 

Result  summary  products  are  specified  by  input  para- 
meters defined  on  card  2.  If  the  parameter  ITWRT  = 1, 
detailed  results  are  written  as  output  in  binary  to  File 
08  for  each  item  simulated.  The  fomat  of  File  08  is 
defined  in  appendix  D of  this  report.  This  file  is  par- 
ticularly useful  for  conducting  involved  post-processing 
calculations  using  statistical  packages  such  as  SPSS  or 
OMNITAB. 

Another  summary  products  are  the  tabular  displays 
and  graphical  outputs  discussed  in  Chapter  III.  These 
products  are  illustrated  in  Figures  III-9  through  III-13 
and  will  not  be  discussed  further  here.  The  tabular 
summaries  are  produced  when  the  pareimeter  lOUT  =»  1,  while 
the  graphical  outputs  are  produced  when  the  parameter 
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In  developing  INSSIM  enhancements,  the  voluminous 
tzibular  summaries  and  graphical  outputs  are  usually  not 
necessary.  Consequently,  einother  form  of  summary  statis- 
tics has  been  developed;  this  abbreviated  output  is  illus- 
trated in  Figure  VII-1,  This  output  product  specifies  key 
performance  statistics  of  particular  interest  in  most 
inventory  simulations.  This  output  is  produced  v^henever 
the  parcuneter  IPUNCH  =1. 

Let  us  now  discuss  debugging  options  available  in  the 
model. 

Debugging  Aids 

Card  3 specifies  the  values  of  five  debug  flags  and  two 
"trace"  variables  that  are  useful  in  debugging  IIISSIII 
enhancements.  Let  us  consider  the  meanings  of  each  of 
these  input  parameters. 

IDBUG.  If  the  input  paraimeter  IDBUG  = 1,  a message 
will  be  printed  each  time  an  event  is  entered  or  removed 
from  the  future  events  list.  Consequently,  this  option 
will  provide  a listing  of  every  event  that  takes  place 
during  a given  INSSIM  simulation  run.  Figure  IV-1  illus- 
trates the  format  and  variable  definitions  associated  with 
these  event  messages.  In  addition,  when  IDBUG  = 1,  stock 
status  information  is  printed  each  time  that  subroutine 
STATN  is  called.  The  format  of  this  output  is  illustrated 
in  Figure  VIII-2,  As  shown  in  the  figure,  this  output 
message  identifies  the  number  of  units  that  are  on-hand. 
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Figure  VIII-1.  Selected  Summary  Statistics  Printed  VThen 
«•  IPUNCH=1 
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Figure  VIII-2.  Intermediate  Results  Output  Options 
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due-in » and  in  a backorder  status.  The  inventory  position 
(INPOS)  is  simply  equal  to  the  sum  of  on-hand  plus  due-in 
assets,  less  any  outstanding  backorders.  The  varicible 
REQ-SHORT  identifies  the  number  of  requisitions  that  are 
backordered  at  that  specific  point  in  time, 

lEDUG,  If  the  parcumeter  IE3UG  = 1,  subroutine  INITEM 
writes  the  details  of  all  item  demand  data  input  from 
File  07,  The  format  of  this  output  message  is  illustrated 
in  Figure  III-2,  and  corresponds  exactly  with  the  data 
layout  specified  in  appendix  A, 

IFDUG,  The  IFBUG  parameter  causes  the  printing  of 
forecasting  information,  as  well  as  the  printing  of  demands, 
serviceable  returns,  and  requisition  frequency  data 
recorded  in  the  current  history  file.  The  format  of  this 
information  is  illustrated  in  Figure  VII-2, 

IGBUG,  The  IGBUG  parameter  causes  the  printing  of 
requisition  generation  events  created  by  subroutine 
DEMPAR,  Figure  VII-2  illustrates  a specific  printout  that 
occurred  when  the  flags  IDBUG  * IGBUG  = 1,  Note  from  the 
figure  that  at  time  100,  a type  12  event  (i,e,,  a DEMPAR 
event)  is  removed  from  the  future  events  list,  \Jhen 
subroutine  DEMPAR  is  called,  the  associated  number  of 
demands  (IDEMMD)  to  be  generated  is  nine,  as  is  circled  in 
the  figure.  The  requisition  generation  process  discussed 
in  Chapter  VI  is  then  initiated.  The  first  requisition 
generated  is  for  a requlstion  size  of  2 units.  Note  that 
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[ this  requisition  for  two  units  (event  code  1)  is  entered 

1.- 

[ on  the  future  events  list  to  occur  at  time  6435.  Note  that 

i . ■ ■ ■ 

I the  second  requisition  is  for  one  unit,  and  that  this 

F 

i second  requisition  is  entered  onto  the  future  events 

I list  to  occur  at  time  8361,  Subsequently,  requisitions  for 

! two,  one,  one,  and  finally  two  units  are  generated  in 

i; 

succession  and  placed  onto  the  future  events  list.  Note 

( 

I that  the  total  of  all  of  these  generated  requisitions 

[ equals  nine  units,  the  total  number  of  units  that  v;ere 

\ present  in  the  demands  history  record  for  the  current  item. 

I Finally,  note  that  a type  12  event  is  placed  on  the  future 

I events  list  to  occur  at  tirae  8500,  This  will  cause  the 

[ next  CALL  to  subroutine  DEMPAR. 

IHBUG.  The  IIIBUG  pareuneter  specifies  the  printing  of 
i levels  that  are  computed  by  subroutine  LEVELN.  The  format 

I of  the  associated  printout  is  illustrated  at  the  bottom  of 

Figure  VII-2.  As  shown  in  the  figure,  the  levels  for  item 
number  1 involve  an  order  quantity  of  14  units,  and  a 

i 

reorder  level  of  7 units.  For  this  item,  termination  and  | 

retention  levels  aire  set  to  very  large  numbers  (99999),  and  ! 

the  support  level  is  set  to  zero,  1 

i 

ITRACE,  ISTP^AC.  At  times,  the  analyst  will  not  want  to  j 

I 

produce  the  many  lines  of  print  that  result  when  IDBUG  =1,  | 

although  he  may  be  interested  in  obtaining  an  event  by  i 

event  printout  during  a specific  time  interval  in  the  i 


simulation.  The  flags  ITRACE  emd  ISTRAC  provide  this 
capability.  The  variable  ITRACE  specifies  the  point 
in  simulated  time  that  a detailed  trace  of  simulation 
events  is  to  start.  At  that  point  in  time,  the  flag  IDBUG 
is  set  equal  to  1.  This  causes  the  event  by  event  printout 
to  start.  The  flag  remains  equal  to  1 until  the  simulated 
clock  time  ISTRAC.  At  this  time,  IDBUG  is  reset  to  zero, 
iuid  the  detailed  event  by  event  printouts  cease. 

This  concludes  our  discussion  of  lilSSIM  output  products 
In  the  next  chapter,  we  will  discuss  the  job  control 
language  statements  required  to  assemble  and  execute 
inssiM  simulation  runs. 


CHAPTER  IX 
JOB  CONTROL  CARDS 


Execution  of  an  INSSIM  simulation  run  is  controlled  by 
a set  of  Job  Control  Language  statement  cards.  These  cards 
cause  the  appropriate  subroutines  to  be  acquired  from  CP.E/\TE 
permanent  files  and  assembled  into  an  executable  package. 

These  routines  also  assure  that  input  files  are  read  from  the 
appropriate  physical  devices,  and  that  output  products  are 
directed  to  appropriate  locations. 

We  have  found  there  are  three  basic  job  streams  that  are 
useful  in  the  conduct  of  an  INSSIIi  simulation  study.  These 
job  streams  are  documented  in  Appendix  C of  this  volume. 

Briefly,  these  job  streams  are  as  follov-’s: 

INSSIM. T This  job  stream  is  used  for  testing  of 

INSSIH  enhancem.ents , and  for  debugging 
newly  developed  subroutines. 

INSSIM. A This  job  stream  provides  for  the  printing 

of  all  INSSIM  input  data,  and  produces 
tabular  summaries  of  simulation  performance 
statistics.  Graphical  displays  of  these 
statistics  as  a function  of  simulated 
time  are  also  produced. 

INSSIM. B This  job  stream  is  used  for  performing 

several  simulation  runs  at  a single  time. 
The  job  stream  is  particularly  useful  in 
developing  cost  ef fectivenesss  curves  for 
alternate  inventory  management  policies. 

In  performing  a given  INSSIM. T study,  it  is  usually  useful 
to  begin  with  the  INSSItl.T  job  stream.  This  job  stream  would 
be  used  for  testing  of  now  code  tliat  defines  forecasting  or 
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r inventory  control  policies  that  are  to  be  evaluated.  In 

i- 

this  stage,  the  detailed  debugging  statements  defines  on  input 
card  4 will  probably  be  used  extensively.  The  INSSIM.T  job 
stream  v;ill  usually  utilize  File  07  input  data  in  free-field 
BCD  format.  No  pre-processing  step  is  necessary  when  data  is 
I input  in  this  form. 

Once  new  calculation  formulas  have  been  fully  debugged, 
the  INSSIM.A  and  INS3IM.B  job  streams  are  employed.  The  IFSSIF.A 
j job  stream  is  useful  for  initial  testing  of  data  to  be  used 

I in  production  runs.  The  graphical  outputs  of  I'lnsiU.d.  are 

particularly  useful  in  determining  whether  there  are  "v/eird" 
data  elements  that  arc  included  in  the  proposed  data  set. 

Once  a data  set  has  been  identified  that  appears  suitable  for 
simulation  study,  the  INSS1I1.3  job  stream  is  utilized.  This 
job  stream  is  designed  to  provide  a large  number  of  simulation 
runs  at  the  lov/est  possible  computer  cost, 
i Both  the  INSSIM.A  and  INSSIM.3  job  streams  utilize  a pre- 

processing step.  In  these  job  streams,  subroutine  DATA32  reads 
input  from  File  07,  and  writes  the  same  data  in  binary  format 
to  File  09.  This  latter  file  then  becomes  input  to  the  INSSIM 
MAIN  program.  In  performing  production  runs,  there  will 
usually  be  a large  amount  of  data  to  be  read  in  through  File  07. 
By  converting  this  information  to  binary,  the  data  processing 
steps  may  be  speeded  up  considerably. 
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